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Chapter 3: Recommended sizing 
procedures 


Meridian IVR software 
Base software packages 


The following software is provisioned according to how many channels are 
requisitioned: 


e Development Base Package (4 channels) 
e Development Expansion Packages (in 4-channel increments) (optional) 


The Development Base Package gives the Meridian IVR system a 4-channel 
capacity. If additional channels are required, capacity can be added by 
purchasing additional channels. This method increases system capacity in 
4-channel increments. 


Note: This is valid only for non-card option systems. For a card option 
Meridian Mail system the minimum channel configuration is 2 and it can 
be incremented in units of two. 


Host communication software 


Host connectivity is supported in Release 2.0/I via the “COMPT”, “COMO”, 
and “COMA” Cells (Host Communication Input, Output, and Abort) for 
Meridian IVR Release 2.0/I. This provides high-level support for the IBM 
/3270 SNA/5250 and VT100 interfaces. By emulating an operator providing 
input and/or retrieving output from a 3270/5250 or VT 100 sessions, the 
Meridian IVR application can easily access required information that is 
normally displayed on the terminal screen. 
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The following templates are needed: 


e Screen templates that define the location of input and output fields on the 
terminal screen. This is accomplished either via row and column offset 
or via a unique field identifier that serves as a tag to identify the field. 


e Action templates that connect the screen templates into a logical 
transaction that must be traversed in order to accomplish the desired 
action. This emulates actions such as a terminal operator entering an 
account number on the first screen, completing the input by then pressing 
a function key, and finally obtaining a screen output that contains the 
desired account balance. 


Host card 


The hardware used to support IBM mainframe connectivity is the EXPRESS 
high performance adapter (SYNC570) card. The SNA/3270 communications 
software, integrated with the host communication cells provides connectivity 
to an IBM mainframe by emulating an IBM 3274 cluster controller with 
3278/3279 terminals. Through customer defined user functions, application 
developers can integrate additional communications software available from 
Apertus. 


This includes: 


Host connectivity through cells: 

e IBM SNA/3270 (including 3274, 3278, 3279) 
e SDLC and over Token Ring 

e WVT100 emulation over serial ports 


e 5250 over token ring (LLC) and SDLC 


Host Connectivity through a user functions (not provided as part 
of the product) 


e Native or LAN Token Ring and Ethernet 
e IBM 3270 over X.25 (European requirement, QLLC) 


e Standard RS232 serial interface 
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5250 host connectivity 


For Meridian IVR Release 2.0/1, in addition to 3270 emulation, the new host 
communication cells will also provide the same level of interface for 5250 
terminal emulation over Token Ring (LLC) or through Expresscard (SDLC). 


Other host connectivity 


Access to hosts using ASCII async (RS232/422), X.25, and Ethernet data 
communications protocols will be facilitated via the use of the User Function 
cell. It will require that the code to support these forms of connectivity be 
written by the application developer in the C programming language. 


For Meridian IVR Release 2.0/I, in addition to 3270 emulation, the new 
“COMTI”, “COMO” and “COMA” host interface cells will also provide the 
same level of interface for VT100 terminal emulation via RS-232. 


To meet international standards, the template files use translation tables for 
character conversion to map to host computers using local variants of 7-bit 
ASCII. Translation tables are provided with the SNA/3270 communications 
software for each language for which character conversion is required. 


Meridian IVR Fax Response software 


Meridian IVR Fax Response is an option for Meridian IVR Release 2.0/I 
which provides send and receive fax capability through the telephone by 
means of DTMF and audio. 


Meridian IVR Fax Response uses the graphic user interface (GUI) on the 
Meridian IVR palette to include fax functions (that is, to receive a fax, senda 
fax, and so on). 


In addition, Meridian IVR Fax Response closely integrates with the data base 
and host computer functionalities on the Meridian IVR. This allows fax data 
to be easily derived from these sources. 


Meridian IVR Fax Response uses Meridian Mail as its voice processing 
platform. 


Meridian IVR Fax response incorporates, in addition to all Meridian IVR 
components, internal fax modems and Meridian IVR Fax Response software. 
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SQL database support 


Structured Query Language (SQL), is a popular user interface for interactive 
database sessions. SQL database support will be an optional feature which 
will only be installed if purchased by the customer. Meridian IVR support of 
SQL makes possible the creation of IVR applications that can interface with 
these databases. 


The SQL interface into the database provides SELECT, INSERT, UPDATE, 
DELETE, and COUNT capabilities (interface cells). 


Eight SQL database configurations will be supported in Meridian IVR 
Release 2.0/1: 

e Local and Remote Informix 

e Local and Remote Ingres 

e Local and Remote Oracle 

e Local and Remote Sybase 

For a SQL database access, the optional SQL package must be ordered and 
the database software required to install and run the local or remote SQL 


database must be purchased by the customer directly from the corresponding 
database vendor. 


Traffic principles 
Terminology 


Centi-call seconds 
This chapter uses the value of centi-call seconds (ccs) to express traffic, 
traffic is calculated as follows: 


Traffic (in ccs) is expressed as the busy hour call volume multiplied by 
the average call length in seconds divided by 100. 


Grade of service 
Grade of service is expressed as GOS. 
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Meridian IVR traffic model 


The traffic model which you design to use with an IVR system depends on 
how the Meridian switch treats incoming calls. 


The IVR system provides a finite number of channels on which calls can be 
processed. If all the channels are busy, the switch can either block incoming 
calls destined for the IVR system, or it can queue up these calls. 


Queueing The queueing model is used by all Meridian IVR systems 
fronted by a Meridian 1 PBX. 


Blocking systems fronted by a DMS will block calls when used in 
conjunction with UCD queues, and the Multi-Line Hunt Group. A Meridian 
1 PBX can also block calls by equating the number of incoming IVR trunks 
to the number of IVR channels. 


Target Grade of Service 


The target Grade of Service (GOS) is a means of simply determining when a 
caller is queued beyond a certain amount of time, or when a caller is blocked. 
A number of factors affect the Grade of Service 


1 the call volume (for example, the number of calls in a busy hour) 
2 the average length of the calls 

3 the number of channels available to service these calls 

4 


whether the channels are dedicated or shared 


Factors | and 2 together make up the traffic intensity. For example, if an 
application expects 100 calls in the busy hour and each call lasts an average 
of 2 minutes, then the traffic intensity on that application is 100 X 120 
seconds, which is 12 000 call seconds or 120 centi-call seconds (120 ccs). 


The GOS is dependent on the call hold time which makes it indirectly 
dependent on the response time characteristics of the application. An 
application with bottlenecks (for example, a slow external host) will lead to 
higher call hold times and, hence, a deteriorated Grade of Service. 
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There is a one-to-one correspondence between the number of Meridian Mail 
channels which may be used for Meridian IVR and the number of Meridian 
IVR channels. Therefore, a 96-channel Meridian IVR system must have 
exactly 96 Mail channels used for IVR in shared or dedicated mode. If IVR 
channels are shared with Meridian Mail services, the traffic generated by the 
mail services affects the GOS for Meridian IVR. 


GOS for queueing traffic model In a queueing traffic model, the 
recommended GOS is a five percent probability that the delay in the queue 
will exceed one ring cycle. This is known as a P.05 GOS. One ring cycle is 
approximately six seconds. 


GOS for blocking traffic model In a blocking traffic model, the 
recommended GOS is a two percent probability that a caller will be blocked. 
This is a P.02 GOS. 


Target response time dependencies 

While the GOS is not directly dependent on MIVR CPU power, the response 
time is. In addition, if external factors like 3270 hosts are present, the 
response time becomes dependent on their response characteristics as well. 


One response time which is always dependent on Meridian IVR is the time 
between when a caller finishes entering DTMF input and when the system 
responds by playing a prompt. This time should be less than two seconds 95 
percent of the time and should average under 1 second. This target should be 
met even if the response time includes local data retrieval. 


Fax response traffic model 


The Fax response traffic model has both queuing and blocking capabilities. A 
pure queuing model is used for Callback fax. The application initiates a 
callback request. The fax is queued up and sent out once it reaches the top of 
the queue and a fax modem becomes free. 
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The Same Call model is more complex. An application wishing to use Same 
Call fax first has to reserve a modem. It is recommended that the modem be 
reserved as close as possible to the time when it is to be used. If a reserved 
modem remains idle for more than five minutes, it is freed up by the system. 
The application can also specify a time that it is willing to wait to reserve a 
modem. The Same Call model thus becomes 


e the blocking model if that time is set to zero 
e the queuing with a time-out model if the time is nonzero 


e the application dequeus if the time in queue reaches a threshold. 


Modems can also be shared between Same Call and Callback usage if all the 
modems in either set are busy. 


Target Fax Grade of Service 
The factors affecting the fax GOS are 


1 the number of faxes requested in a busy hour 

2 the average number of pages and their resolution 
3 average rendering time per page 
4 


the number of fax ports available 


Fax rendering and sending are one operation to an IVR application. 
Therefore, factors 2 and 3 determine for how long a fax port is held. Together 
with factor 1, they determine the fax traffic intensity. 


The Fax GOS is important in a Same Call situation because the fax operation 
will take place on the same IVR call. The GOS is the probability that a fax 
modem does not become available in a certain time (which could be 0). 


The target GOS for Callback fax is a measure of the probability that a fax 
sitting in the queue waiting to go out exceeds a certain time limit. This is 
important when an IVR application promises to send a fax within a certain 
time. 


Another factor which may affect Callback fax is the probability that the 
remote machine is busy. If the fax is being sent with a retry option, it will be 
queued up again. For the purposes of this document, this factor is ignored. 
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Fax on demand (Callback delivery) 

The Fax Application traffic must be estimated and channel requirements 
determined for the number of faxes requested in the busy hour. This is done 
by 

e estimating the average session length for each defined fax application 

e estimating the expected maximum number of busy hour calls to that 


application 


The traffic from a “Callback” fax delivery should include the duration of the 
call to receive the request, and also the duration of the call that delivers the 
faxes. The call receiving the request consists of the following components 


e time to listen to voice menus (15 seconds) 
e time to select options (10 seconds for each option selected) 


e time to enter callback number and extension (30 seconds) 
The session time for each fax delivery can be estimated as follows 


e a 10-second time to set up the call 
e a 14-second time to answer call 
e a 12-second time to establish protocol 


e 40 seconds per page in normal resolution and 80 seconds per page in fine 
resolution 


e a 10-second time to complete fax delivery 


This assumes that the fax will be delivered on the first attempt. Additional 
time should be added if this is not the normal case. 


When the application is running, the fax delivery report can be periodically 
monitored to see if the actual wait times are within the desired limits. 


Fax on demand (Same Call delivery) 

The Voice Menu traffic must be estimated and channel requirements 
determined for the number of faxes requested in the busy hour. This is done 
by estimating the average session length for each menu defined, the number 
of pages in the fax to be delivered, and the expected maximum number of 
busy hour calls to that menu. 
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The traffic from a Same Call fax delivery call should include the following 
components: 


e timeto listen to greeting prompt 
e time listen to voice menus and select as many faxes as required 
e time to receive ‘Same Call’ faxing instructions 


e time to transmit the faxes selected 


— a12-second time to establish protocol 


— 40seconds per page in normal resolution and 80 seconds per page in 
fine resolution 


— a10-second time to complete fax delivery 


Tables have been generated for fax session lengths of 234 seconds (3.9 
minutes). The tables indicate the traffic which can be handled by a given 
number of multimedia channels. Refer to the Fax GOS tables in Appendix G: 
"Erlang tables" on page G-1 for more information. 


Note: An analysis was done for fax session length and number of pages 
in each fax at the TOR site (for MM9). The average session length was 
234 seconds and the average number of pages in each fax was 4.8. These 
figures were considered a useful starting point for the fax traffic tables 
used in this document. 


Fax storage limit 

Since all fax data is stored under a single directory hierarchy, standard UNIX 
utilities (du) can be used to determine when fax storage has been exceeded. 
The system will not receive any more faxes when the file system threshold is 
exceeded. 


Hard disk storage 
At 60 Kbytes per Fax page, approximately 30 Mbyte of disk space is needed 
for 500 pages of Fax data. 


Second hard disk 

The second Hard drive is used when a large area for Fax storage is required, 
or Database software and other data has occupied a large amount of hard disk 
space so there is not enough space for the Fax data. The size of the second 
hard disk is 1012 Mbytes in total. When the Meridian IVR system has been 
installed there is 10.31 Mbytes free disk space remaining. 
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Notes: 
1 The second hard disk is used only for storing the Fax data. 


2 There is only one partition on second hard disk (sdisk). 


Storage calculations 


There are two primary components of capacity for every Meridian Mail 
system: channels and hours of storage. The size of the system, in channels and 
hours, determines the number of users who can use the system, and the level 
of service that Meridian Mail/IVR provides. 


Channels 

The number of channels on a system determines the number of users who can 
access IVR at one time. For example, a 12-channel system allows twelve 
users to use IVR at any one time. 


Hours of storage 

All the voice prompts (system as well as prompts and voice messages 
recorded by Meridian IVR) are stored in Meridian Mail mailboxes. Individual 
mailboxes can contain a maximum of six hours of voice storage. Hours of 
storage must be determined as the accumulated storage requirements of the 
total number of mailboxes used by the Meridian IVR system. 


Types of channels 


Meridian Mail channels for Meridian IVR can be configured as dedicated or 
shared channels. If dedicated, the channels are used for Meridian IVR only, 
while shared channels are used for Meridian Mail or Meridian IVR as 
determined by the incoming call. 


The channels dedicated to Meridian IVR can be common to all Meridian IVR 
applications or can be dedicated to specific Meridian IVR applications only. 
This allocation of channels has a direct impact on the number of channels that 
have to be provisioned. 
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By dedicating channels, you can control the Grade of Service and caller 
access, but channel use will be less efficient. In this document, three grades 
of service are discussed: two percent delay, five percent delay, and a 
recommended grade. Two and five percent refer to the percentage of callers 
that will experience a delay, that is, to wait in a queue before their call is 
answered. When a delay is experienced the average is about a 10-second 
delay. The average delay of all callers will be well under one second. 


At the recommended Grade of Service, the average delay of callers 
experiencing a delay will be about 10 seconds, and the average delay for all 
callers will be under two seconds. Such delays would be expected during the 
busy hours. At other hours with less traffic, delays will be less frequent. 


Estimating the number of channels 


Channel requirements are determined using standard traffic engineering 
principles that take into account busy hour traffic and the desired Grade of 
Service. The busy hour is the highest traffic hour for a customer. For Meridian 
Mail/Meridian IVR, traffic capacity is stated in ccs, hundreds of seconds of 
connect time per hour. Refer to “Traffic principles” on page 3-4 in this 
chapter for more information about determining traffic capacity for your 
Meridian IVR system. 


Determining requirements 

You must analyze the customer’s specific applications before you can 
determine the channel requirements for Meridian IVR. Meridian IVR channel 
requirements can vary widely in terms of the number of calls requiring 
processing and the holding times of those calls. 


To ensure that Meridian Mail provides adequate capacity, follow these steps 
for each Meridian IVR application: 


1 Estimate the average length of a call in seconds. An average holding time 
for a short IVR application may be 60 seconds, while a lengthy IVR 
application may be 300 seconds. 


2 Estimate the number of calls per busy hour. 


3 Estimate the total traffic load for Meridian IVR in ccs by multiplying the 
step 1 estimate by the step 2 estimate and dividing by 100. Do this for 
each planned application. 
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4 Decide whether channels for these applications will be shared or 
dedicated between Meridian Mail and Meridian IVR. If Meridian IVR 
will share channels with Meridian Mail voice messaging, you only need 
to add this traffic to Meridian Mail voice messaging requirements. By 
dedicating channels, you can control the Grade of Service and caller 
access, but channel use is less efficient. It the application will have 
channels dedicated to it, you need to designate channels per service 
configuration. 


5 To determine the fewest number of channels required to accommodate 
the total activity for the system, use the number from step 3 and refer to 
Table G-1 "Grade of service and traffic formula" on page G-1 to find the 
number that best accommodates the total activity calculated above given 
the Grade of Service required. 


Note: Outbound applications (those which make calls) require 
dedicated channels. 


6 For each group of applications that share common channels, sum the 
traffic loads from step 3. 


7 To determine the fewest number of channels required to accommodate 
each group of applications, use the numbers from Step 5 to find the 
number of channels that best accommodates the total activity calculated 
above given the Grade of Service required. 


8 The total of the numbers from step 6 gives the number of channels that 
are required to accommodate the total activity for the system. 


Note: Meridian IVR supports a maximum of 48 channels and up to 24 
shared (dynamically allocated) channels. See Table 3-7, ACCESS link 
capacity limits, on page 3-21. 
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Example of multiple application requirements 

A customer has three Meridian IVR applications. The main IVR application 
answers all calls to the company, and will invoke the other two IVR 
applications, IVR2 and IVR3 if necessary. All three applications use the same 
dedicated Meridian IVR channels. The average delay for callers must not 
exceed one second, and no more than five percent of the callers should 
encounter a delay in the busy hour (this equates to a five percent delay Grade 
of Service). 














Table 3-1 
Example table for GOS P.05 
Procedure Step 1 X Step 2 = Step 3 
Application Calls in Busy | X Holding Time Total Time 
pp Hour (seconds) (seconds) 
Main IVR 200 X 20 4000 seconds 
IVR2 20 X 240 2400 seconds 
IVR3 30 X 180 5400 seconds 
Total Time 32000 seconds 
or 118 ccs 

















Total system activity for all IVR applications is 106 ccs. Refer to Table 3-1 
for 106 ccs and the recommended Grade of Service. Total port requirements 
are 8 ports for IVR. 


Example of multiple fax application requirements 


The customer has four IVR applications, the main IVR application 
(IVR_MAIN) answers all calls to the company and walks the caller through 
the fax menu. 


The customer has three other IVR fax applications: [VR_Fax_1, IVR_Fax_2 
and IVR_Fax_3. 


The typical session duration for the IVR_MAIN menu is 45 seconds (time to 
listen to the voice menu, plus time to select an option, plus time to enter the 
callback number if required): 


e IVR_Fax_1 is 214 seconds (4.8 pages of fax in standard resolution) 
e IVR_Fax_2 is 480 seconds (6 pages in fine resolution) 
e IVR_Fax_3 is 382 seconds (3 pages) 
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For simplicity assume that [VR_Fax_1 and IVR_Fax2 will use Callback 


channels, and IVR_Fax_3 will use Same Call channels. 


Table 3-2 
IVR_Fax_1 holding time values 





Measurable actions 


Time (in seconds) 




















listen to fax menu 25 
time to set up call 10 
time to answer call 14 
time to establish protocol 12 
time to complete fax delivery 10 
Add (for 4.8 pages, standard (4.8 * 40) 


format): 


Holding time: 


Table 3-3 
IVR_Fax_2 holding time values 








263 seconds 








Measurable actions 


Time (in seconds) 




















listen to fax menu 25 
time to set up call 10 
time to answer call 14 
time to establish protocol 12 
time to complete fax delivery 10 
Add (for 3 pages, fine format): (3 * 80) 


Holding time: 
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Table 3-4 


IVR_Fax_3 holding time values 
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Measurable actions 


Time (in seconds) 


















































listen to fax menu 55 
time to establish protocol 12 
time to complete fax delivery 10 
Add (for 3 pages, standard (3 * 40) 
format): 
Holding time: 197 seconds 
Table 3-5 
Example table for GOS P.05 and P.02 
Procedure Step 1 Multiply Step 2 = Step 3 
o gt Calls in Holding Total 

Application Busy Hour x Time (seconds) | Time (seconds) 
IVR_MAIN 30 
IVR_Fax_1 10 X (25+10+14+12+ 2630 
(Callback) 10+(4.8 * 40)) 
IVR_Fax_2 10 X (25+10+14+12+ 3110 
(Callback) 10+(3 * 80)) 
IVR_Fax_3 10 X (55+12+10+(3 * 1970 
(Same Call) 40)) 
Total Time for 5,740 
P.05 (Callback) (57 ccs) 
Total Time for 1970 
P.02 (Same 
Call) (20 ccs) 
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Total system activity for all Callback IVR Fax applications is 57 ccs and 20 
ccs for Same Call Fax applications. Refer to the Fax GOS tables in “Appendix 
G: Erlang tables” on page G-1 for 57 ccs and 20 ccs the recommended Grade 
of Service. 


Total port requirements for Callback ports are five ports and three ports for 
Same Call Fax. 


In some cases, when it is determined that the use of Callback channels is high 
in certain hours and may exceed the limit where use of Same Call channels is 
low, it is a good idea to turn some of the Same Call channels into Shared 
channels or vice versa. 


Ongoing channel sizing 


After the Meridian Mail system is installed, the system administrator uses 
Operational Measurements reports to provide statistics on system traffic and 
activity. By monitoring these reports, the administrator can keep track of 
system capacity and forecast when, and if, an increase in the number of 
channels is required. 


Note: If dedicated channels are used, Meridian IVR acquires the 
channels permanently when the application is started, and Meridian Mail 
Operational Measurements reports the channels as active from the time 
the Meridian IVR application is running. Therefore, the Meridian IVR 
Call Detail report should be used to determine actual ccs for applications 
using dedicated channels. Alternatively, Meridian MAX reports provide 
a view of actual call traffic on Meridian Mail channels. 














Table 3-6 
Port addition increment for Fax and IVR 
Minimum # of pain X Maximum # of 
IVR Ports $ y channels 
increment of 
8-Mbyte Card Option 2 2 12 
Other supported 4 4 96 
MMail platforms 
Fax option 2 1 8 
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Control of maximum number of channels 


Meridian IVR controls the utilization of Meridian IVR channels purchased by 
customers. Keycodes are used to restrict the customer from using more than 
the number of channels purchased. 


The maximum number of fax ports available to the customer are also limited 
if the Fax Response option is purchased. 


Deciding between dedicated and shared channels 


Meridian Mail channels can be dedicated to Meridian IVR, or they can be 
shared with other Meridian Mail services like call answering. Consider the 
following points when deciding between shared and dedicated channels: 


1 


The traffic intensities of the IVR applications and Meridian Mail should 
first be considered separately. 


If one intensity is low compared to another, it may be better to dedicate 
the appropriate numbers of channels separately. A guideline is if one is a 
tenth of the other. For example, if IVR traffic is going to be 6 ccs and 
mail traffic 60 ccs, size each service separately and dedicate the channels 
separately. 


If both are roughly equal, it may be better to share channels so that, if 
unexpected peaks occur, there is a bigger pool of channels to draw upon 
depending on the busy hours. 


The traffic patterns of the two services should be considered when 
sharing channels. If the busy hours coincide, then the traffic intensities 
should be added up to give total traffic, and this figure would be used to 
determine the number of channels. 


If the busy hours are separated, then the busy hour with greatest traffic 
intensity should be used in determining the number of channels (for 
example, if both IVR and call answering have busy hour traffic of 60 ccs 
each, but IVR busy hours are in the morning and call answering busy 
hours in the afternoon). There is also a constant call answering load of 10 
ccs in the morning and 5 ccs of IVR in the afternoon. 
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In this example, the morning busy hour load is 70 ccs and the afternoon 
load is 65 ccs. Thus, 70 ccs would be used in sizing the system. 


3 There may be a case where the decision is made in the context of the 
service being offered. In the case of a service provider, the provider may 
be selling channels to customers. Here, obviously, the channels would be 
dedicated and sized by the intensity and GOS which the customer wants. 


Shared channels put a slight overhead on Meridian Mail. The advantage is 
that there is a bigger pool of channels to draw upon for unexpected peaks. 
Also, there is a limit of 24 channels per ACCESS link, (running at 9600 baud) 
which can be shared with Meridian Mail services. For more information see 
Table 3-7, ACCESS link capacity limits, on page 3-21. 


Note: The Voice Prompt Editor needs one shared channel. 


Sharing channels among IVR applications 


This is another option where the application to be executed is dependent upon 
the called number. All 96 IVR channels can be shared amongst Meridian IVR 
applications. 


Outcalling applications 


A Meridian IVR application can use the outcalling feature. Depending on the 
numbers and length of these calls, a number of outcalling channels must be 

configured. This number is determined in the normal way although the GOS 
can be lessened depending on the application (a machine is calling now and 
it can try again if it is blocked). These channels cannot be used for incoming 
calls. 


Determining hours of storage 


The Meridian IVR prompts and incoming voice messages recorded by 
Meridian IVR are stored in Meridian Mail mailboxes. Each Meridian Mail 
mailbox can contain a maximum of six hours of voice storage. All voice 
prompts used by Meridian IVR and all voice messages recorded by Meridian 
IVR, must fit into this limit. If the six-hour limit is not sufficient, multiple 
mailboxes must be assigned. 
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Estimates must be made to determine the amount of storage (expressed in 
hours) that all of the prompts for the IVR applications will take prior to 
creating a storage mailbox for the Meridian IVR system. This can be easily 
performed by examining the nature of the prompts, (for example, are they 
short or long), and the quantity of prompts for all of the IVR applications that 
will exist. Also, determine if voice messages will be created by the IVR 
application and the amount of storage required to support them. A good 
starting value for an IVR mailbox is 90 minutes. 


Meridian Mail mailboxes are assigned to channels during the initial 
configuration of Meridian IVR, and multiple channels can use the same 
mailbox. The exact allocation of mailboxes will be determined by the nature 
of the applications. In a simple case, one mailbox is used for all Meridian IVR 
channels, and the prompts for all applications are stored in that single 
mailbox. 


To minimize the storage requirements of the mailboxes, individual 
applications can be assigned to different groups of channels and each group 
of channels then use one mailbox. In this case, the full set of application 
prompts are not stored in each mailbox, rather only the application prompts 
required by the applications assigned to a group of channels are stored in that 
one mailbox. 


System prompts must exist in every mailbox, regardless of the storage 
requirements of the mailbox. If more than 24 channels use a single mailbox, 
there may be a performance degradation when the Meridian Mail system is 
used. To avoid this situation, a second mailbox should be assigned on a 
different Meridian Mail node, and the channel allocation should be divided 
between the two mailboxes. 


Notes: 


1 Since Meridian Mail Release 8 has fully implemented the prompt 
caching feature, it is unnecessary to create a second mailbox to store 
duplicate IVR prompts on 24-channel and larger systems. 


2 While a Meridian Mail system is engineered to provide one to three 
minutes of storage per user, limits on the maximum amount of 
storage can and should be set higher for Meridian IVR mailboxes. 
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Estimating the amount of voice storage 

The size of the mailbox is dependent on the number of languages used. An 
initial value to start off with is 90 minutes of storage for two languages. This 
would be on top of Meridian Mail requirements if the system was also used 
for voice mail. 


If applications take voice messages, then they must make sure that the 
messages are removed from the prompt mailbox and delivered to a user 
mailbox. This would then be considered a voice mail use and must be 
included in the standard Meridian Mail voice storage determination. 


Note: The storage requirement for Meridian IVR system prompts is 50 
minutes. 


To determine disk size for Meridian Mail 


1 Determine the number of mailboxes that will be allocated to Meridian 
IVR. 


2 Estimate the total hours of storage required for Meridian IVR prompts 
for each mailbox. 


3 Add the amount of storage required for transaction messaging for each 
mailbox. 


4 If Meridian Mail is used for voice menus or voice processing, this 
amount must be added to the amount of Meridian Mail storage calculated 
(see Site and Installation Planning Guides (NTP 555-70xx-200). 


Ongoing disk management 


Operational Measurement reports allow the system administrator to monitor 
the disk usage and to forecast when additional storage space will be needed. 
The actual amount of storage used for [VR mailboxes can be examined by 
means of Meridian Mail administration. This is also the means by which 
storage can be increased if required. 
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Performance tips 


1 Combine as many prompts together in a PLAY or PDAT cell as the 
application permits. 


2 Play prompts from one voice segment file instead of interspersing 
prompts that will be played together or back to back across multiple 
voice segment files. 


3 Dedicated channel acquisition improves IVR performance during call 
start-up on a per call basis resulting in better performance system wide. 


Determining the correct number of ACCESS links 


Table 3-7 
ACCESS link capacity limits 





The following table describes the ACCESS link capacity limits for shared and 
dedicated modes. Use this table to calculate the correct number of ACCESS 
links for your system. 


























Forone Number of Number of Number of PUMDET of 
ACCESS onae ae PAOA Applications 
ener Applications Applications Applications 

link (in the (Channels) at 
following (Channels) at (Channels) at (Channels) at 38,400 
mode): 4,800 bps 9,600 bps 19,200 bps (MM10) bps(MM10) 
Dedicated 18 38 76 96 
mode 
Shared 8 18 38 96 
mode 
Note: The recommended connection procedure is to connect the 
ACCESS Link to the Voice Nodes and not to connect more then one 


ACCESS Link to a Node. 
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Database servers and host sessions 


There can be a maximum of 50 SQL servers, and 64 3270 SNA/5250 and 15 
VT100 sessions. The numbers of these are dependent on the access time to 
the database or host. If the total call time is T seconds and, of that, SQL or 
host access time is a total of t seconds, then one SQL server or one host 
session can support T/t channels of that application. However, a safety 
margin should be applied and each server or host session should support only 
T/2t channels. 


For example, say a 64-channel system is used and each call lasts 100 seconds. 
Say that total host access time for the whole call is 10 seconds; then each 3270 
session can support 5 channels. Thus, 64 channels would need 64/5 or 13 
sessions. 
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Memory and CPU requirements 


Table 3-8 
Scenario table for Memory and CPU requirements 





Memory CPU 


Customer will require the following features a P 
required required 





Scenario 1: - 32 IVR Channels 32 Mbyte 75 MHz 
- 2 ACCESS Link 





Scenario 2: - 16 IVR Channels 32 Mbyte 75 MHz 
- 4 Fax port 
- 1 ACCESS Link 





Scenario 3: - 24 IVR Channels 32 Mbyte 75 MHz 
- 2 ACCESS Link 
- 3270 SDLC, 9 sessions 
- UPS Option 





Scenario 4: - 80 IVR Channels 48 Mbyte 75 MHz 
- 4 ACCESS Link 


Scenario 5: - 64 IVR Channels 48 Mbyte 75 MHz 
- 4 ACCESS Link 
- 4 Fax port 





Scenario 6: - 48 IVR Channels 48 Mbyte 75 MHz 
- 4 ACCESS Link 
- 4 Fax port 
- 5250 LLC, 18 sessions 
- UPS Option 





Scenario 7: - 96 IVR Channels 64 Mbyte 100 MHz 
- 6 ACCESS Link 
- 8 Fax port 
- 5250 SDLC, 27 Session 
- UPS Option 
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Table 3-8 
Scenario table for Memory and CPU requirements (Continued) 





Memory CPU 


Customer will require the following features . s 
required required 








Scenario 8: - 96 IVR Channels 64 Mbyte 100 MHz 
- 6 ACCESS Link 
- 8 Fax port 
- Fully Installed Local Oracle database 


(Approximation, 10 Mbyte of DRAM 
usage) 





Scenario 9: - 96 IVR Channels 80 Mbyte 100 MHz 
- 8 ACCESS Link 
- 8 Fax port 
- Fully Installed Local Oracle database 


(Approximation, 10 Mbyte of DRAM 
usage) 


- 3270 SDLC, 32 sessions 
- UPS Options 

















Memory sizing 
Memory is an important factor limiting the capacity and feature set of the 
Meridian IVR 2.0/I system. 


This section highlights under what conditions (installing different features) 
different memory configurations should be determined. 


The point system 


The “point system” can be used to determine which combination of features 
and capacity will fit on a particular Meridian IVR 2.0/I system. All 
calculations are based on total system memory. The value of one “point” is 
equal to 150 Kbyte. 
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Caveats: 


1: This point system is not intended to accurately predict the free 
memory for the system, but rather to predict which combinations of 
features can be installed before exhausting available memory on the 
system. 


2: Values expressed in both Table 3-9 and Table 3-10 are derived from 
measurements on the Meridian IVR 2.0/I system. 


Table 3-9 
List of Meridian IVR Processes 

















Points 
32 48 64 80 96 128 
Process Mbyte Mbyte Mbyte Mbyte Mbyte Mbyte 
System | System | System | System | System | System 
Total permitted Swapping 48 48 48 48 48 48 
Total physical memory 218 328 437 546 655 765 
Operating System usage 68 68 68 68 68 68 





Total Available Points 198 308 465 526 635 745 


Combined IVR Memory usage summary 




















IVR & Access 96 96 96 96 96 96 
Each IVR channel 2 2 2 2 2 2 
Each ACCESS Link 4 4 4 4 4 4 
Fax Option 25 25 25 25 25 25 
Each Fax port 2 2 2 2 2 2 
Host Option 3270 & 5250 15 15 15 15 15 15 
Host Option VT100 0 0 0 0 0 0 





























Meridian IVR Planning and Engineering Guide Product release 2.0/I 


3-26 Recommended sizing procedures 


Table 3-9 
List of Meridian IVR Processes (Continued) 








Process Mbyte Mbyte Mbyte Mbyte Mbyte Mbyte 





Each Host session H H H H H H 
(3270,VT100 and 5250) 


H= 2 If # of sessions <9 

H= 4 If # of sessions <18 
H= 6 If # of sessions <27 
H= 8 If # of sessions <32 





UPS Option 12 12 12 12 12 12 





SQL (Local or remote)? 





Capacity Factor is designated P P P P P P 
as P. The value of P is dependent 
on the number of IVR channels. 


P=7 If channels <12 
P=13 If channels <24 
P=17 If channels <48 
P=20 If channels <64 
P=25 If channels <96 





























a. To find out about your SQL database memory requirements (that is, Oracle, Informix, Sybase and Ingres) 
please consult the appropriate vendor documentation. You must determine your requirements in Kilobytes, 
then divide it by 150 (to get the value in points) after that you can use the value in this table to determine your 
total memory usage. 


The following example illustrates how the point system can be used to 
determine the correct memory size for an Meridian IVR system. 


555-9001-200 Standard 1.0 February 1996 


Recommended sizing procedures 3-27 


All calculations are based on the following feature set: 


32 ports of IVR (all shared channels meaning more than one ACCESS 
link will be required, 9600 baud Link) 


2 ACCESS Links 
Fax Option with 4 ports 
UPS option 


Use Table 3-9 for determining memory size. 


Sample procedure for determining correct memory size 


1 


Add the core software memory usage for IVR and Fax: 


96 (IVR) + 25 (Fax) = 121 


Add the channel points for IVR and Fax: 


2 (per IVR channels) * 32 (required channels) + 4 * 4 
(required fax channels) = 88 


Calculate ACCESS Link points: 4 * 2 (ACCESS Links) = 8 
Check the UPS requirement: 12 points 


Find the Capacity Factor for your system (in our case since we have 
32 IVR channels the factor is: 17 


Add all of the above calculated points: 


121 + 88 + 8+ 12 + 17 = 246 


Compare the calculated points with the available points for 32, 64, 96 
or 128 Mbyte system memory, in this case we can not use 32 Mbyte 
system since it does not give us enough memory (Total available 
memory points is 198) so we have to use next step up memory 
configuration which is 64 Mbyte of DRAM (417 points). 


Meridian IVR Planning and Engineering Guide Product release 2.0/I 


3-28 Recommended sizing procedures 


CPU sizing 


This section highlights under which conditions different CPU sizing is 
recommended. 


The same “point system” used for calculating memory requirements can be 
used to determine which combinations of features and capacity will fit on the 
Meridian IVR 2.0/I system in terms of CPU load. (See “ The point system” 
on page 3-24 for clarification, if needed). 


Points are based on total system CPU loading (100 points in total). The point 
system is not intended to accurately predict the CPU load for the system, but 
rather to predict which combinations of features can be installed before 
exhausting available CPU cycles on the system. 


All values in the table are derived from measurements on the Meridian IVR 
2.0/1 system. Calculated values over 100 points (Max 110) indicate that a 
faster CPU is required. 


























Table 3-10 
CPU point requirements 
Points (CPU Loading Factors) 
Total Available Points For a 75 MHz For a 100 MHz 
System System 

IVR (Generations & Access) 25 25 
Fax Option 15 25 
Each Fax port 4 4 
Host Option (Core) 18 18 
UPS Option 5 5 
SQL (Local and remote) (25 and 15) (25 and 15) 
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Table 3-10 
CPU point requirements (Continued) 





Points (CPU Loading Factors) 





Total Available Points For a 75 MHz For a 100 MHz 


System System 








Capacity Factor: P P 
P= 10 If # of IVR channels <12 
P= 13 If # of IVR channels <24 
P= 18 If # of IVR channels <48 
P= 22 If # of IVR channels <64 
P= 30 If # of IVR channels <96 


Total Available Points 100 (Max 110) 122 (Max 134) 











The following example illustrates how CPU sizing should be implemented. 
All calculations are based on the following feature set: 


e 64 ports of IVR (all shared channels meaning three ACCESS link will be 
required) 


e Fax Option with 8 ports 
e Host Connectivity (3270 SNA) 
e UPS option 


Use Table 3-10 for determining CPU size. 


Sample procedure for determining correct cpu size 
1 Add the CPU Loading point requirement for desired feature set: 


25 (IVR) + 15 (Fax) + 8 (fax ports) * 2 + 18 (Host 
Connectivity) + 5 UPS = 79 


2 Find the Capacity Factor for 64 IVR channels: 22 
3 Add all of the above calculated points: 79 + 22 = 101 


In this case faster CPU is not required since we are not exceeding the CPU 
Loading point (100 with Tolerance of 10 for 75 MHz CPU). 
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Disk sizing 
The hard disk space required for different Meridian IVR 2.0/I options is 
documented under “Disk usage” on page 4-10. For additional information 
regarding third party software disk space requirements (for example, Oracle 
or Informix) please consult the appropriate manufacturer’s documentation. 
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